Tested this PR with real world keys

• Tested with GOOGLE_APPLICATION_CREDENTIALS and ~/.config/gcloud/application_default_credentials.json and verified the new tagged enum is used in both cases
• Tested with service account key, user creds, and an impersonated service account and verified that I can make API calls

Hi @djc, @msdrigg - we are really interested in service account impersonation (we use bigtable-rs that uses this crate under the hood). What is the current status of this PR? If there's any more work needed, I'd be happy to help.

This PR worked at the time I tested it, but I have not tested it in 2 years as you can see and now there are merge conflicts. The work that needs to be done is:

0. Get by-in from djc
1. Resolve any merge conflicts
2. Retest with real keys

There's quite a bit of code here and it's not obvious to me why we need a separate FlexibleCredentialSource enum layer at all. Also note that at this point I'm a volunteer maintainer -- if your team depends on this project, please consider sponsoring my work.

So there is definitely some code here that can be trimmed down, but you still need some kind of flexible deserialization to cover these variables:

1. Reading GOOGLE_APPLICATION_CREDENTIALS file could contain service account or impersonated service account (different deserialization)
2. The source_credentials field on ImpersonatedServiceAccountCredentials can either be another service account or a user account.

So you basically do need something like FlexibleCredentialSource to handle this tagged enum deserialization.

I think to make this less recursive and potentially more readable, you could pull out something like this into types.rs

#[derive(Deserialize, Debug)]
struct ImpersonatedServiceAccountCredentials {Expand commentComment on line R112Code has comments. Press enter to view.
    service_account_impersonation_url: String,
    source_credentials: ServiceAccountOrUserAccount,
    delegates: Vec<String>,
}

enum ServiceAccountOrUserAccount {
    // ... tagged deserialization of service account or user account
}

// Actually deserialize this for your credential type
pub(crate) enum ServiceAccountOrImpersonatedServiceAccount {
    // ... tagged deserialization of service account or impersonated service account
}

In my PR, I combined both of these situations into a single recursive FlexibleCredentialSource, but I get that is kind of a big change that is harder to review for correctness.

I actually might could do this change to my PR and re-push it if you think it would be a welcome change djc

You added a bunch of code, seemingly duplicating a bunch of logic, which I'm not excited about. I'd be open to reviewing the very minimal changes I could facilitate to enable you to build this downstream, and then we can review whether it makes sense to support it as part of this project (which I think might make sense, but not in its current form).

What changes would you be supportive of to make this work downstream? I am still interested in making this happen but I am not sure what you mean.